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MEMORANDUM TOR: Deputy Director for Administration 


EROM : Bruce T. Johnson 
OLrector of Data Processing 


SUBJECT: THSA Draft Report to BXCOS 


1. In the attachment, identified by paragrauh and page 
number, are comments reflecting my concerns about specific 
portions of the Draft THSA report. More general comments fcllow 
below. 


2. As we discussed during our meeting on “ednesday, 
17 June, many of the “key problems" covered by the report are «ore 
properly the concern of the DEA, not the EXCOM, Ont even those 
items which require MXCOM attention should be subjected to 
coordination at the Directorate level before being elevated for 
EXCOM review. 


3. During the sometimes heated dentate which preceded the 
decision to create an Architect's position and thus enhance the 
Agency's ability to plan effectively for tomorrow's information 
systems, the question arose whether this new function should have 
line authority. In short, did the Agency need an information 
czar? In the most dramatic option considered, such a czar would 
have been set up as a Deputy Director for Infornation, but other 
possibilities for exercising authority were also ‘iscussead, ane 
all were vociferously rejected. In its final report the Informa- 
tion Handling Task Force concluded: “In gum, it was the concensus 
of the Executive Committee that the only change in Agency level 
management justified at this time is the creation of a Syste 
Architecture function to plan for future information syst : 


which would in fact create the kind of line management authority 
rejected by the previous EXCOM when decidin; to esttblish the 
position. I strongly oppose establishing such line authority for 
the IHSA, and believe the DO's will do so as well. 
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4. The report should be completely recast to emphasize 
Planning, data collection, data flow, standards, training, ete. 
All proposals for modification of existing review and approval 
processes should be removed, and a set of procedures should he 
@eveloped and carefully coordinated before submission to the 
EXCOM, Ratification of these procedures can then be based on the 
knowledge that the BD's and their staffs have had « hand in the 
development process. Concurrently, a new statement of THSA 
functions and responsibilities, based on the Th PF study, should os 
submitted for coordination. 


/s/ Bruce T. Johason 


Bruce T. Johnson 


0/D/ODP/BJohnson:ee/23 Jun 81 
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19 June 1981 


D/ODP Comments on 
“Review of the IHS Architectural Functions in the Agency" 


Section 1, third paragraph (Page 2) 


[ _]ldefines ODP's responsibilities in applications 
development and in reviewing proposed acquisitions of ADP 
equipment and systems. It does not define ODP's charter, which 
is in 


of 16 March 1981 was not coordinated and, as written, 
could not have obtained Agency-wide coordination. The reference 
ignores DDA's decision to return to the charter as enunciated by 
the IHTF. : 


Section 1, fourth paragraph (Page 2) 


This discussion of the Paperwork Reduction Act of 1980 omits 
reference to the requirement that the senior IHS official also 
exercise any delegations of procurement authority issued under 
the Brooks Act by GSA. Any recommendation which does not also 
cover the all-important DPA would be deficient. (ADDA has a copy 
of ODP's paper to OGC on this subject.) 


Section 2, first paragraph (Page 3) 


I am not familiar with the “old aphorism", but in ODP-developed 
systems users and developers set requirements. They need access 
to information about ways in which the proposed system relates to 
other, possibly unseen requirements. We don't need 
accreditation, we need a dependable cross-directorate source of 
information and guidance. 


Section 2, third paragraph (Page 4) 


I don't understand this. PERSIGN surely has as many potential 
"adjunct" users as any system we've ever built. (Perhaps we need 
a definition of "adjunct user.") LIMS will replace many 
dissimilar smaller logistics systems. Is that bad? 
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Section 4 (Pages 7, 8) 


Robustness is a legitimate goal, and ODP welcomes support for our 
on-going effort to improve availability and reliability. The 
discussion here is confusing however, stating on the one hand 
that a lack of robustness leads to lowered availability but on 
the other that robustness contributes little to performance. In 
ODP reliability is the number one priority, and with each 
incremental modification we grow more "robust," in terms of 
system availability. Still lacking, of course, is a remote back- 
up center, which would indeed cost money and not add 
commensurately to daily availability, unless disaster struck one 
of our centers. 

The reader is led by this section to conclude that there exists — 
no commitment to user friendliness today. On the contrary, user 
convenience dictated much of the design of the DD 7260, and is 
the watchword of the development of the user language for SAFE. 
We picked GIMS in 1971 because of its strong user language. 


Section 5 (Page 8) 


This Agency has always depended on contractors for the majority 
of scientific programming support. The central investment in 
such support in ODP has never been large. As noted in a recent 
report to the DDA on Scientific Programming Support to NFAC (ODP 
81-296 dated 6 March 1981), we have increased our contract 
support for OSWR and are negotiating for additional rotational 
slots where we can place resident specialists with the requisite 
skills. Apparently the IHSA has identified some other needs not 
known to us. I would like to know what they are. What specific 
problems are we trying to solve? 


Section 6, first paragraph (Page 9) 


IHS appears to be equated here with ADP technology. The IHTF 
(page 1-3) defined IHS much more broadly, and I believe the 
separate treatment of IHS and ADP is useful, the latter being 
only a subset of the former. 


Section 6, seventh paragraph (Page 10) 


I don't know how or on what basis the IHSA arrived at these 
conclusions, but I would greatly appreciate an opportunity to 
have our management of on-line storage audited carefully before 
statements of this kind are presented to the EXCOM. A “use it or 
lose it" policy has been in effect in ODP/Engineering for some 
years. Are we trying to maximize the efficiency of people 
(growing more expensive) or machines (growing cheaper)? 
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Section 6, ninth paragraph (Page 10) 


ODP should have an opportunity to be heard on these matters 
before these issues go to the EXCOM. It might interest the IHSA 
to know that if measured in constant dollars the non-personal 
services of ODP which cost[ Jin 1979 will be delivered in FY 
83 for $2 million less, while our capacity will have increased by 
60% to 85%, depending on the type of service in question. What 
"efficiency" problems are we trying to solve? 


Section 6, eleventh paragraph (Page 11) 


We already have nearly Se | 
concurrent users as our Service base in VM. The increase refers 


to is, I assume, in part SAFE, for which a new center is being 
installed. What is the basis of these figures? 


Section 6, paragraphs 12 and 13 (Page 11) 


How do NARS regulations, archaic or otherwise, relate to the 
question of efficient use of computer resources? I too am 
concerned about digital records in the records management 
environment, but NARS regulations, except for those governing 
procurement, do not figure largely, if at all, in our day-to-day 


Management of ADP resources. What is meant by "wasteful and non- 


productive service and administrator requirements"? 
Recommendation 1 (Page 12) 


The proposed format leaves unclear how organizations like OC and 


ODP with [Seer Fo all involving "IHS's," 
would do their jobs. The procedures outlined here would involve 
the EXCOM in the day-to-day management of these offices. 


I do not quarrel with the split of responsibilities suggested 
here, with ADPE review in ODP and "systems" (needs defining) 
review in IHSA. I do not see how the IHSA staff can "delegate" 
responsibility to a line organization, but am prepared to have 
"embedded ADPE" referred to ODP for review. The division should 
be stated in relevant regulation, not left to "delegation." 


Recommendation 2 (Page 12) 
No problem. 
Recommendation 3 (Page 13) 


As the IHSA and OTE know, I consider the study at Appendix B to 
be a flawed document. I urge DDA to consider carefully before 
submitting it in ics present form to the EXCOM. The data behind 
the study are shakey, and the conclusions may be quite 
misleading. That we need to increase our committment to training 
in the uses of information technology is not contested, 

however. 
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Recommendation 4 (Page 13) 


This issue of tasking authority came up during last year's EXCOM 
debate and was noisily opposed. I predict strong opposition this 
time as well, and share in that opposition. 


Authority to review and "adjust" resource allocations is also 
likely to run into a corporate buzz-saw. 


Recommendation 5 (Page 14) 


Of the[ sj in the enhanced package for 1983, [_]are for ODP, 25X1 
and all are allocated to high-priority needs, such as [ ]to the 25X11 
new payroll. If we are to be asked to create a scientific pro- 

gramming unit the positions will have to be provided. 


\ 


The "IHS services" referred to are in fact central ADP services, 
which is to say ODP services. Before we undertake "to develop a 
set of recommended techniques for controlling the efficiency of 
utilities" for these services we should review the current 

service philosophy which governs our Management of ADP resources 
and ascertain whether we have a real problem. What "inefficiency" 
problems are we trying to solve? 


Recommendation 7 (Page 14) 


If this means bypassing coordination, I disagree. 
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